-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Examples Overhaul #6060
Examples Overhaul #6060
Conversation
…ames and commented scripts
…der structure with other dist elements
@@ -10,7 +10,7 @@ | |||
"build:metadata": "node ./scripts/metadata.mjs", | |||
"build:sharing": "node ./scripts/sharing-html.mjs", | |||
"build:standalone": "node ./scripts/standalone-html.mjs", | |||
"build:thumbnails": "npm run build && node ./scripts/thumbnails.mjs", | |||
"build:thumbnails": "node ./scripts/thumbnails.mjs", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We discussed this a bit here: #5555 (comment)
Basically it allows for a cold start - but I also agree that it takes quite some time before building thumbnails. @mvaligursky Do you have an opinion on this?
IMO in the best case, we could build the thumbnails while not wasting any time running rollup/node processes beforehand - it's technically doable, that's why I used index.js
in the example dir which linked every example. By virtue of ESM you could get a list of every example viaexport * from ...
the index.js files - acting as single-source-of-truth instead of possibly outdated generated metadata files. The importmap would resolve everything in node_modules
and the only thing eventually required is a npm install
. I still like that idea more than making us indebted to all kinds of build scripts.
(rollup still has its place of course for generating minified builds for publishing)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well currently this would only be required when modifying or creating new examples now since thumbnails are included in the repo itself now.
Yea having the thumbnails resolved using the imports I don't like since it splits how the example names are generated from folder and file names to the names specified in the import index.js
files. One workaround would be setting file path in the config
to read after the import is resolved but that seems messy.
Additionally you don't need to add example to some index file when generating a new one you can simply add the file within the specified folder.
What is the build process for this in relation to the engine? Does it still rely on building the engine first, or can we just import directly?
|
Yea, it still relies on |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks and works great!
Refers #6030
This PR aims to align the examples experience to of using the engine in a standalone app.
Changes
example
function and arguments and put body into example script global scope (app is now accessed by usingexport { app };
at the bottom of the script)example
into modules to load in for each scriptassetPath
,glslPath
etc) to arootPath
which serves all static filesDemo
This PR has a lot of changes it so I have provided a demo serving these changes.
https://kpal81xd.github.io/playcanvas-examples
Preview
ToDo
observer
to use moduleconfig.mjs
fromexamples.config.mjs
I confirm I have read the contributing guidelines and signed the Contributor License Agreement.